Explicación de la integridad del entorno web
Autores:
Ben más sabio (Google)
Borbalá Benko (Google)
Philipp Pfeiffenberger (Google)
Serguéi Kataev (Google)
Participar
Tabla de contenido
Introducción
Los usuarios a menudo dependen de que los sitios web confíen en el entorno del cliente en el que se ejecutan. Esta confianza puede asumir que el entorno del cliente es honesto acerca de ciertos aspectos de sí mismo, mantiene seguros los datos del usuario y la propiedad intelectual, y es transparente sobre si un humano lo está usando o no. Esta confianza es la columna vertebral de una Internet abierta, fundamental para la seguridad de los datos de los usuarios y para la sostenibilidad del negocio del sitio web.
Algunos ejemplos de escenarios en los que los usuarios dependen de la confianza del cliente incluyen:
A los usuarios les gusta visitar sitios web que son costosos de crear y mantener, pero a menudo quieren o necesitan hacerlo sin pagar directamente. Estos sitios web se financian con anuncios, pero los anunciantes sólo pueden permitirse pagar para que los vean humanos, en lugar de robots. Esto crea la necesidad de que los usuarios humanos demuestren a los sitios web que son humanos, a veces mediante tareas como desafíos o inicios de sesión.
Los usuarios quieren saber que están interactuando con personas reales en sitios web sociales, pero los malos actores a menudo quieren promover publicaciones con una participación falsa (por ejemplo, para promocionar productos o hacer que una noticia parezca más importante). Los sitios web solo pueden mostrar a los usuarios qué contenido es popular entre personas reales si son capaces de conocer la diferencia entre un entorno confiable y un entorno no confiable.
Los usuarios que juegan en un sitio web quieren saber si otros jugadores están usando software que hace cumplir las reglas del juego.
A veces, los usuarios son engañados para que instalen software malicioso que imita software como sus aplicaciones bancarias, para robarles a esos usuarios. La interfaz de Internet del banco podría proteger a esos usuarios si pudiera establecer que las solicitudes que recibe en realidad provienen del software del banco o de otro software confiable.
La relación de confianza entre sitios web y clientes se establece frecuentemente mediante la recopilación e interpretación de información altamente reidentificable. Sin embargo, las señales que se consideran esenciales para estos casos de uso de seguridad también pueden servir como una huella digital casi única que puede usarse para rastrear a los usuarios en todos los sitios sin su conocimiento o control.
Nos gustaría explorar si un mecanismo de menor entropía (Integridad del entorno web) podría ayudar a abordar estos casos de uso con una mejor privacidad respetando las propiedades.
Integridad del entorno web
Con la API de integridad del entorno web, los sitios web podrán solicitar un token que atestigua datos clave sobre el entorno en el que se ejecuta su código de cliente. Por ejemplo, esta API mostrará que un usuario está operando un cliente web en un dispositivo Android seguro. Se evitará la manipulación de la certificación firmando los tokens criptográficamente.
Los sitios web decidirán en última instancia si confían en el veredicto emitido por el certificador. Se espera que los verificadores normalmente provengan del sistema operativo (plataforma) por una cuestión práctica, sin embargo, esta explicación no prescribe eso. Por ejemplo, varios sistemas operativos pueden optar por utilizar el mismo certificador. Esta explicación se inspira en las señales de certificación nativas existentes, como App Attest y Play Integrity API .
Existe una tensión entre la utilidad para casos de uso antifraude que requieren veredictos deterministas y una alta cobertura, y el riesgo de que los sitios web utilicen esta funcionalidad para excluir verificadores específicos o navegadores no verificables. Esperamos con interés el debate sobre este tema y reconocemos el importante valor añadido incluso en el caso de que los veredictos no estén disponibles de forma determinista (por ejemplo, los que se resisten a hacerlo).
Objetivos
Permita que los servidores web evalúen la autenticidad del dispositivo y la representación honesta de la pila de software y el tráfico del dispositivo.
Ofrecer una solución antiabuso, sólida y sostenible a largo plazo.
No habilite nuevas capacidades de seguimiento de usuarios entre sitios mediante la certificación.
Continúe permitiendo que los navegadores web naveguen por la Web sin certificación.
No goles
Habilite la validación confiable de veredictos en el lado del cliente: las firmas deben validarse en el lado del servidor, ya que el javascript del cliente puede modificarse para alterar el resultado de la validación.
Hacer cumplir o interferir con la funcionalidad del navegador, incluidos complementos y extensiones.
Acceso a esta funcionalidad desde contextos no seguros .
Casos de uso de ejemplo
Detecta manipulación de redes sociales y engagement falso.
Detectar tráfico no humano en publicidad para mejorar la experiencia del usuario y el acceso al contenido web
Detectar campañas de phishing (por ejemplo, vistas web en aplicaciones maliciosas)
Detecte intentos de secuestro masivo y creación masiva de cuentas.
Detectar trampas a gran escala en juegos web con clientes falsos
Detecte dispositivos comprometidos donde los datos del usuario estarían en riesgo
Detecte intentos de apropiación de cuentas identificando la adivinación de contraseñas
Cómo funciona
Hay un mínimo de tres participantes involucrados en la certificación de integridad del entorno web:
La página web que se ejecuta en el navegador web de un usuario.
Un tercero que puede "dar fe" del dispositivo en el que se ejecuta un navegador web, denominado certificador.
El servidor de desarrolladores web que puede verificar de forma remota las respuestas de certificación y actuar en base a esta información.
Una página web solicita una certificación de entorno al certificador con un "enlace de contenido". El enlace de contenido garantiza que incluso si un atacante intercepta una atestación, no podrá usarla para dar fe de una solicitud modificada. La certificación es una descripción de baja entropía del dispositivo en el que se ejecuta la página web.
Luego, el certificador firmará un token que contiene la certificación y el enlace de contenido (denominado carga útil) con una clave privada. Luego, el certificador devuelve el token y la firma a la página web. La clave pública del certificador está disponible para que todos la soliciten.
La página web devuelve esta información al servidor web. Luego, el servidor web verifica que el token provenga de un certificador en el que confía e inspecciona la carga útil del token. Verifica la carga útil verificando la firma con la clave pública del certificador.
Opcionalmente, el servidor web puede llamar al punto final del servidor del certificador para obtener señales adicionales (de baja entropía), por ejemplo, para detectar dispositivos potencialmente hiperactivos.
¿Qué información hay en la certificación firmada?
La propuesta requiere al menos la siguiente información en la certificación firmada:
La identidad del certificador, por ejemplo, "Google Play".
Un veredicto que indique si el certificador considera que el dispositivo es confiable.
Todavía estamos discutiendo si se debe incluir cada uno de los siguientes datos y agradecemos sus comentarios:
El veredicto de integridad del dispositivo debe ser de baja entropía, pero ¿qué granularidad de veredictos deberíamos permitir? Incluir más información en el veredicto cubrirá una gama más amplia de casos de uso sin bloquear dispositivos más antiguos. Un enfoque granular resultó útil anteriormente en la API Play Integrity.
La identidad de la plataforma de la aplicación que solicitó la certificación, como com.chrome.beta, org.mozilla.firefox o com.apple.mobilesafari.
Algún indicador que permita limitar la velocidad frente a un dispositivo físico
Creemos firmemente que los siguientes datos nunca deben incluirse:
Un ID de dispositivo que es un identificador único accesible para los consumidores de API.
¿Cómo puedo utilizar la integridad del entorno web?
Hay dos pasos para utilizar la integridad del entorno web para los desarrolladores. El primer paso es solicitar una certificación de integridad del entorno en la página web y enviarla al servidor web.
// getEnvironmentIntegrity expects a “content binding” of the request you are
// about to make. The content binding protects against this information being
// used for a different request.
// The contentBinding will be concatenated with eTLD+1 and hashed
// before it is sent to the attester.
const contentBinding = `/someRequestPath?requestID=xxxx` +
"Any other data needed for a request-specific contentBinding...";
const attestation = await navigator.getEnvironmentIntegrity(contentBinding);
console.log(attestation.encode());
"<base-64 encoding of the attestation payload and signature approx 500 bytes; see below for details>"
// More on attestation validation below
const response = await fetch(`/someRequest?requestID=xxxx&attested=${attestation.encode()}`);
// Do something with this ...
El token de certificación se devuelve mediante un ArrayBuffer serializado con CBOR (RFC 8949) y firmado mediante COSE (RFC 9052). Encontrará más información sobre el contenido del token de certificación en la especificación.
El segundo paso es en su servidor web, donde verifica que la información certificada sea válida utilizando la clave pública del certificador y luego toma decisiones basadas en la información reportada.
// None of the code below is part of the Web Environment Integrity API being
// proposed. This is an example of how you can verify the environment's integrity
// on your web server.
function isAttested(attestation, contentBinding) {
if (!isAttesterTrustedByMe(attestation)) {
return false;
}
// The attester's public key is retrieved directly from the attester.
const attestersPublicKey = getAttestersPublicKey(attestation);
// We then validate the attestation token using the attester's public key.
// We also check the content binding and replay protection in the attestation.
if (!isTokenRecentEnoughAndValid(attestersPublicKey, attestation)) {
return false;
}
// Check contentBinding hash in attestation
// Make decisions using the attestation.payload
// ...
}
Desafíos y amenazas a abordar
Calidad de los atestiguadores
Web Environment Integrity no prescribe una lista de certificadores específicos o condiciones que los certificadores deben cumplir para convertirse en certificadores. Los navegadores deben publicar sus requisitos de privacidad para los verificadores y permitir que los sitios web evalúen la utilidad de cada certificador por sus propios méritos. Los usuarios también deben tener la opción de excluirse de los verificadores que no cumplan con sus expectativas personales de calidad.
Seguimiento del historial del navegador de los usuarios
Los agentes de usuario no proporcionarán ninguna información de navegación a los verificadores cuando soliciten un token. Estamos investigando una división entre emisor y certificador que impide que el certificador rastree a los usuarios a escala, al tiempo que permite inspeccionar un número limitado de certificaciones para su depuración, con informes de transparencia y auditabilidad.
Toma de huellas dactilares
Esta explicación requiere que se firme el contenido de las cargas útiles de certificación. Esos contenidos no pueden ser alterados o no serán dignos de confianza. Solo los verificadores pueden incluir información que pueda identificar usuarios/dispositivos.
Todos los campos devueltos por los verificadores deben ser de baja entropía para no ser identificables de forma única. Por ejemplo, los verificadores pueden especificar bajo/medio/alto para una puntuación de confianza en lugar de un valor numérico continuo. Las cargas útiles de certificación solo incluirán información sobre la integridad del dispositivo y de la aplicación, ya que los verificadores no tendrán acceso a la información del perfil en las aplicaciones.
¿Cómo podemos asegurarnos de que los verificadores no devuelvan respuestas de alta entropía?
En el corto plazo, para la experimentación, el certificador debería declarar públicamente lo que está atestiguando, con veredictos legibles y verificables.
Más allá de la fase de experimentación, necesitamos un método verificable para imponer respuestas de baja entropía. Nos gustaría explorar opciones como dividir las funciones de certificador y emisor de tokens de una función a dos organizaciones independientes, donde el emisor de tokens pueda verificar que la respuesta de certificación cumpla con los requisitos de entropía.
Seguimiento entre sitios
Si bien los tokens de certificación no incluirán información para identificar a usuarios únicos, los tokens de certificación en sí podrían permitir el seguimiento entre sitios si se reutilizan entre sitios. Por ejemplo, dos sitios en colusión podrían descubrir que el mismo usuario visitó sus sitios si un token contiene claves criptográficas únicas y fue compartido entre sus sitios.
El navegador debe imponer la partición de nivel superior para todos los tokens de certificación, de modo que dos dominios no puedan conspirar para rastrear al usuario entre sitios utilizando este mecanismo. También tenemos la intención de limitar la vinculabilidad entre las partes de confianza (sitios web que solicitan certificación) y el certificador de una manera que evite el seguimiento escalado incluso si el certificador estuviera en connivencia con los sitios web, al tiempo que permitimos la depuración de certificaciones rotas.
La partición será diferente para diferentes perfiles (por ejemplo, los perfiles de incógnito obtienen particiones diferentes incluso si es el mismo sitio que el usuario visitó en su perfil habitual). El usuario también debería poder restablecer el estado que produce estos tokens, rompiendo la vinculabilidad incluso dentro de la misma partición.
Los metadatos de certificación en sí deben esforzarse por lograr una entropía mínima y, al mismo tiempo, proporcionar niveles de confianza, enumeraciones y/o indicadores binarios útiles.
Discusión detallada del diseño.
¿Por qué no utilizar JWT en lugar de CBOR?
Cuando se trata de tráfico de mil millones de qps, el diseño debe tener en cuenta la sobrecarga de ancho de banda que agrega a los usuarios de la web. CBOR minimiza el tamaño de la carga útil de las solicitudes mientras sigue decodificando/codificando en JSON.
Web Authn ya ha sentado un precedente al utilizar CBOR. Tiene sentido utilizar un formato de certificación similar en ambas especificaciones para fomentar la adopción.¿Cómo afecta esto a las modificaciones y extensiones del navegador?
Web Environment Integrity da fe de la legitimidad de la pila de hardware y software subyacente, no restringe la funcionalidad de la aplicación indicada: por ejemplo, si el navegador permite extensiones, el usuario puede usar extensiones; Si se modifica un navegador, el navegador modificado aún puede solicitar la certificación de integridad del entorno web.
Alternativas consideradas
Haga de esto una extensión de la API de recuperación
Una vez que un cliente web ha realizado una verificación inicial del entorno en el que se ejecuta, debería tener más confianza al ejecutar solicitudes de certificación localmente. Desacoplar las solicitudes de certificación de la recuperación permite a los desarrolladores web la oportunidad de realizar estas comprobaciones en las llamadas importantes, sin agregar gastos generales al resto.
Los desarrolladores también pueden utilizar esta API con sockets web. Introducir esta API primero como primitiva nos permitirá desarrollarla en una etapa posterior.
Pase de privacidad/Tokens de acceso privado
Apple y Cloudflare han desarrollado tokens de acceso privado para un caso de uso similar, y Chrome también ha creado tecnologías basadas en PrivacyPass (tokens de estado privado). Sin embargo, debido a los tokens completamente enmascarados, esta tecnología supone que el Attester puede producir una certificación sostenible y de alta calidad sin ningún comentario de los sitios web sobre lagunas como falsos positivos o falsos negativos.
Estamos convencidos de que la durabilidad de una solución de certificación de dispositivos depende de la presión del adversario y de la capacidad del defensor para continuar fortaleciendo el sistema contra las tácticas y técnicas de abuso en constante evolución. Por lo tanto, buscamos una solución que permita la depuración de falsos positivos y falsos negativos y al mismo tiempo evite el seguimiento escalado.
Preguntas abiertas
¿Cómo evitaremos que esta señal se utilice para excluir proveedores?
Proporcionar una señal que sea exclusiva del certificador podría ser peligroso si los sitios web deciden admitir a los certificadores solo cuando ciertas señales estén disponibles. Si los sitios web saben exactamente qué navegador se está ejecutando, algunos pueden negar el servicio a los navegadores web que no favorecen por cualquier motivo. Ambos van en contra de los principios a los que aspiramos para la web abierta.
Los atestados deberán ofrecer su servicio en las mismas condiciones a cualquier navegador que desee utilizarlo y cumpla con ciertos requisitos básicos. Esto lleva a que cualquier navegador que se ejecute en la plataforma del sistema operativo determinada tenga el mismo acceso a la tecnología, pero aún corremos el riesgo de que 1) algunos sitios web puedan excluir algunos sistemas operativos y 2) si la identidad de la plataforma de la aplicación que solicitó la certificación está incluido, algunos sitios web pueden excluir algunos navegadores.
Aguantar
Para protegernos contra ambos riesgos, estamos evaluando si las señales de certificación a veces deben retenerse para una cantidad significativa de solicitudes durante un período de tiempo significativo (en otras palabras, en un pequeño porcentaje de pares (cliente, sitio), las plataformas simularían clientes que no soportan esta capacidad). Tal retención alentaría a los desarrolladores web a usar estas señales para análisis agregados y reducción oportunista de la fricción, en lugar de una lista cuasi permitida: una retención evitaría efectivamente que la certificación se use para controlar el acceso a funciones en tiempo real, porque de lo contrario el sitio web corre el riesgo de que los usuarios de la población retenida sean rechazados.
Aunque una retención impediría que la señal de certificación se utilice para decisiones de cumplimiento por solicitud, sigue existiendo un inmenso valor para la medición en poblaciones agregadas.
Sin embargo, una retención también tiene importantes inconvenientes. En nuestra encuesta de capacidades y casos de uso, hemos identificado una serie de casos de uso críticos para la certificación determinista de la integridad de la plataforma. Estos casos de uso actualmente se basan en la toma de huellas digitales del cliente. Una certificación determinista pero de entropía limitada obviaría la necesidad de tomar huellas dactilares invasivas en este caso y tiene el potencial de marcar el comienzo de más prácticas positivas para la privacidad en el largo plazo.
Solicitamos comentarios del grupo comunitario sobre la idea de una retención y estamos muy interesados en sugerencias alternativas que permitan cumplir ambos objetivos.
Política de navegador aceptable a nivel de attester
Si la comunidad cree que es importante que la certificación incluya la identidad de la plataforma de la aplicación, y está más preocupada por excluir ciertos navegadores que excluir ciertos sistemas operativos/certificadores, podríamos estandarizar el conjunto de señales que los navegadores recibirán de los certificadores, y tener una Una de esas señales es si el certificador recomienda el navegador para que los sitios confíen (según criterios de aceptación bien definidos). A medida que se introduzcan nuevos navegadores, tendrían que demostrar a los evaluadores (un grupo relativamente pequeño) que pasan el listón, pero no necesitarían convencer a todos los sitios web del mundo. Los navegadores establecidos solo necesitarían utilizar certificadores que respondan de manera rápida y justa a las solicitudes de los nuevos navegadores para ser confiables.
¿En qué se diferencian los WebViews?
Las WebViews están integradas en aplicaciones nativas que tienen acceso directo a las API de certificación que exponen más información de la que estaríamos dispuestos a proporcionar en la web. Estas aplicaciones pueden exponer el acceso directo a esas API, por lo que tiene sentido relajar algunas de las restricciones que proponemos para las API web anteriores. En particular:
La API WebView no tiene las mismas preocupaciones con respecto a la dependencia del proveedor.
La API WebView puede exponer información sobre la aplicación del incrustador bajo ciertas condiciones (por ejemplo, suscripción voluntaria).
Comentarios/oposición de las partes interesadas
[Es posible que los implementadores y otras partes interesadas ya hayan manifestado públicamente sus posiciones sobre este trabajo. Los enumeraremos aquí con enlaces a evidencia según corresponda.]
[Implementador A]: Positivo
[Parte interesada B]: Sin señales
[Implementador C]: Negativo
[Cuando sea apropiado, explicaremos las razones dadas por otros implementadores para sus preocupaciones.]
Referencias y agradecimientos
Muchas gracias por los valiosos comentarios y consejos de:
Nick Doty por ayudar a identificar las preocupaciones de los usuarios en una propuesta inicial .